Quote from Flame CZE :

By the way, as EQ Worry created PTH files for some new tracks, I think it would be quite easy to count the track length, wouldn't it? That info could be displayed in the !tr table.

Yes, this calculations already works. If a supported track/layout combo is recognized and the appropriate PTH file exists, track length is calculated.

Aaaaahhh, goood! Where do I find more info about this pls?

PS: Nevermind, if it is just the small notice in the Z30 patch thread, found it...

PPS: Having the positions by split times is not the most precise thing, still a very good one.

Last edited by EQ Worry, Thu, 28 Apr 2011 14:58.

Quote from Crady :

How can it happen that a "unnamed" player is listed in our pm list? We didn´t add him...

Uhm, sorry, I'm not sure what you mean by a PM list?

Quote from SJB :

Any possibility to realize a wrong way check on the new X tracks of Z30?

I'm working on such functionality. It is quite complicated, because special new PTH file needs to be created for each open tracks, and then a routine must be running assigning node numbers to each car, etc. This is still in the testing phase, but AIRW personal and world best lap times seem to be working. When released, all this will be available only in the PROS version, and probably only for specific layouts. For more info check out this thread.

The layouts for the new tracks I've seen and implemented so far are cool - simple and effective. As for the split/finish positions, they can be anywhere, the "original" positions do not matter.

I'm doing the PTH files mainly to be able to have clean/good lap times and all this stuff. That's good, because the path check itself can then make sure the lap times were done using the correct roads (as outlined by layouts).

The slight problem is that LFS reports very little about loaded layouts: Just the name, number of splits, number of objects. To be reasonably sure the correct layout is loaded (not just some other layout with name changed) I'm thinking about implementing a relatively simple check, reading the layout file directly and probably checking on the splits/finish position only. But that means Airio must be running locally...

Uhm, well...

Thanks for the feedback! I'll try to prepare some more tracks that look reasonable and are quick to be compiled. The PTH files are important, because they allow to see positions in race (based on nodes), do proper path checks, see idling and wrong way driving etc. Yes, with PTH files present the exact track length is calculated, as you can see in !tr. (E.g. the K31 length is something like 9800 meters.) I'm using the layouts downloaded about 4 days ago from the OP. For now the only thing that should not change in layouts is the split/finish line positions, because that would invalidate some data/info. Adding barriers somewhere to prevent driving to closed parts of the site/track is no problem.

Nice development with the layouts!

Meanwhile, I'm extending the Airio framework so that some of the new tracks are sort of standardized and recognized as something people may score PBs and set WRs at, through the AIRW database. At present four tracks are supported: A11, A21, A22, K31, plus the reversed directions. Correct path is being checked, so that there can be clean laps for WRs. It seems the lap time data are correctly stored and retrieved from AIRW. Also the race positions are being calculated, currently shown only as Px on splits in the leftmost of Airio timing buttons. I'll probably try to talk to Deko of NDR (I guess he runs the Z30 server) and offer this updated Airio for stress-testing.

What other new/alternate tracks of the layout pack you think would deserve to be fully supported using Airio/AIRW? It is quite easy to support tracks that just combine standard paths. It is much harder to define completely new turns and parts of tracks. And, frankly, would you be interested in having such support? I see many people have fun just with the layout, never mind no data being stored and no race positions/flags are available.

Extremely good job with the layouts!

I was working on racing/timing support for some new open layout tracks. I'm happy to say that I have the basic framework working. This includes recognizing some custom tracks, assigning nodes to all cars, which is a base for determining their position in race (not implemented yet), and also path checks for server and AIRW laps.

Anyone interested in checking out the basic open track Airio functions, still in testing mode and not complete (!), jump to the & LFS Z30 Airio server. Currently, K31 track is running there. All commands such as !tr or !sb should work. Also clean laps should be saved as AIRW best/good lap times.

Feedback is most welcome!

LFS Z30 is released. When you have time, could you please prepare layout for AS11 or AS12? Then I could start with some experiments...

I guess the release is very near now. As a test I created two more PTH files for two more tracks. Now there is AS21 and AS22 (these were easy to make, because they're just combinations of the existing AS2 and AS3). Also KY31 is now prepared (and it was not so easy, because of two completely new turns). Pictures are appended, the nodes could be used in an intermediate InSim applications for evaluating race positions, wrong way driving, etc. Anybody knows a fast algorithm to find out using X and Y location coordinates to what node (very small sector) they belong?

Ah, right! That explains it. Thanks for information!

Very nice! For how long is this InSim.Net library available? I needed a library like 2.5 years ago. Did I miss it then or is it newer than that? Certainly professional work! Congrats!

Quote from Scawen :

... the new, accurate collision system ...

I wonder if this also covers contacts between cars, so that there is less crazy results of small touches, especially in open wheelers. That would be awesome, but even if that's not the case, it is great to see a serious progress in LFS.

You may also check out the Aegio InSim .NET library, it is part of all Airio/Aonio downloads (see my signature below). Thoroughly tested in just about every aspect, but not really documented and also, as of now, not an open-source. Based on .NET 2.0, works on Linux with Mono too.

Having the gear available in MCI would be nice, as there are some cheats giving XFG/XRG a 6th gear. But again, it is best to release the patch as soon as possible and maybe add such suggestions later, if reasonably possible. Just my view though.

Quote from Takumi_lfs :

No major changes are made.

No dispute. But adding lots of little things that were missing makes it up for me. And the open track possibilities are great, though not readily available.

Yes, indeed, it is possible to cancel restart/end/qualify vote through InSim, though not immediately (after 1st vote), but only when the vote is really called by the server (more than half the people voted). But that's OK, no problem there. All that's needed, in my view, is the possibility to cancel kick/ban votes, and only those votes. If /ck does that and only that, I'm absolutely happy.

Quote from Scawen :

I think it is a little better than you imagine ... two packets must be in reasonable agreement ... I have implemented a /cv command for admins or hosts ... About the InSim version, I could increase it.

Fantastic about the 2 collision packets sent by clients and combined! Indeed, that is much better than I imagined. Very nice.

Also BIG thanks for the /cv command! I can't wait to test it. My only concern is that e.g. ban vote can run together with restart vote, and /cv will cancel both. Quite often there are situations, when only one type of vote needs to be canceled (either ban vote or restart vote) and the other should run. Sometimes I need to cancel restart vote but kick/ban is allowed. Other times kick/ban needs to be canceled, but restart voting should continue.

Concerning InSim version, maybe that Zero byte (4th) in IS_VER could be used for sub-version as eg. InSimSubVer? It was always 0 up until now. It could be 1 for Z30, making this InSim version 4.1, an update of 4.0. But it is a "header" byte, so I'm not sure if that's possible.

Again, thanks for all these explanations. The only thing that seems to be a problem to me now is the universal /cv command, which, if I understand it correctly, affects two different and not really related types of voting.

Quote from fat-oil :

Nothing would be sent under 0.5m/s sounds weird to me.

Maybe the collision packet could still be sent, simply with 0 as the severity (speed)?

Last edited by EQ Worry, Fri, 22 Apr 2011 10:07.

For me the new packet and structure looks great, but I really cannot say now if they prove to be usable for reliable crasher detection. Unfortunately, lags are always influencing many things. I guess we all know situations when you brake on time, but the car in front of you is obviously pushed and slides away though you never touched it. But you lagged a bit, the server saw you braking 0.5 s later than you really did, and processed the inexistent collision. Now it will send a collision packet with lots of precise data, that are not so precise in fact. And cascading effect is also possible, cars hitting each other as a result of the first small lag.

So, I think it is great to have the car collision packet with some data available. But only practice (months of testing/development) will show what data are actually usable and reliable for whatever crash-detection routines someone develops. Having some spare bytes both in the collision packet and the car structure looks like very good idea to me. Also, I consider the impact speed resolution of 1 m/s as sufficient. Car speed is updated only 2 or 3 times per second on server, so again, it will never be precise and highly reliable factor.

I hope the object collision packet will make it into InSim. That would be nice to have for clean laps detection. Also nice would be to have the InSim version raised to 5 (or whatever), so that InSim libraries can easily detect they can use the collision packets and longer messages etc. And I very very much hope a kind of /stopvote command, canceling the running kick/ban vote, will make it into patch Z30. It is the thing I miss most. And maybe that Ctrl+Shift pressed bit in OutGauge. Sorry for repeating myself and BIG thanks for all this development!

OK, I will answer here. This is the problematic part, copied from CG forum:


PB not saved but AIRW accepted? Shouldn't it be the other way, AIRW in fact more strict than local PBs? No, not really.

The AIRW PB is done with a custom car. AIRW will accept ANY lap time as a new PB in a supported custom car, as long at it has all required split times as well. If works just like LFSW lap times, everything is accepted, no checks. The strict AIRW checks are applied only for good/best online laps, in standard and custom cars. So, for personal best anything is possible. For good/best lap strict checks apply.

As for PB not saved because of unclean lap, there is OffPath value in TCD file. This value makes the standard (strict) path wider in both direction by the specified value in meters, and if CheckRacePath is true in SRV, only PBs done on this (wider) path are saved. So, probably, the OffPath value is set pretty low and there was a small lag or visit too far outside the proper race track, so the PB was not stored locally.

Hmm, I see. You can maybe check one thing: Every time (I believe) you enter track with car a number is shown under live PB time, in gray. That is the lap time the live timing is being compared to, so maybe you can check if it is about the same as the local PB?

Hmmm, hard to comment on this. Just a reminder though, that the live comparison works only with best laps done with version 1.5.0, not some previous version. Only 1.5.0 is storing time/node/speed data into special files which are then used for live comparison. The personal comparison base is then updated only when you improve your lap time by about at least 0.1 seconds, because that is the sampling resolution. So it may be showing –1.0 seconds as live comparison, but +0.25 on splits using PB comparison. That's because the PB was done with earlier version, without sampling data. And you were not yet that fast with 1.5.0.

Last edited by EQ Worry, Mon, 18 Apr 2011 11:22.

Quote from PMD9409 :

Would you know how to go about making it a "new track" from a layout? It sounds pretty tricky.

Well, I've been already hinting about a possible way to achieve this, incl. positions in race. But only outside LFS itself, meaning for InSim applications. It could go like this: There'll be a small intermediate InSim application with just a few functions. The main InSim (Director, Airio, etc.) will connect not to LFS, but to this intermediate application.

The intermediate application will just forward most of the packets received to the main InSim, but it will slightly modify some info. Based on layout detected (and using some layout checks) this app will report a new custom track (4 chars) in packets where track name appears. It will also process car locations (X,Y,Z) and using a custom-created PTH file (see one of my previous post with image appended) it will determine car nodes and also positions in race. Tricky, but possible, I think.

Based on these calculations it will slightly modify e.g. the MCI packets, so that node number and race position is included there for each car. In theory, that could make Director fully operational. Hopefully.

Still, race positions will not be available through LFS itself, but if the modified data are fed e.g. into Aonio, which features multi-purpose race position list, it should again work just as if LFS itself was supplying the data.

Uhm...

Well, yes, I understand. My point is that it would be great to have these X and Y layouts appear as completely new LFS tracks, not as layouts. So that if e.g. AIRW is used to store/display unofficial online WRs on these new tracks, it would receive/show only e.g. A11R or K20 as the track name. The same for storing PBs locally e.g. in Airio, for !sb and !pb and !tm and other commands. It will be a new track, not some layout on the open X or Y sites. I'm not sure if I can explain this properly.

Well, the problem is the position of start/finish line + splits in a layout are reported using node numbers. And those X and Y tracks will have no nodes, so almost nothing would be available to InSim applications concerning the actually loaded layout.

There are ways to overcome that limitation, like using a CRC check or something on the layout file, as Dave of CG suggested, or maybe even parsing the LYT file and seeing the X,Y,Z placement of important things, but overall it is not really easy. At least I do not see an easy way.

All current tracks have 3 splits max plus start/finish. LFSW, AIRW and Airio, Lapper (plus maybe other tools) rely on this fact that there can be max. 4 sectors on any track. So again, adding a 4th (or higher) split could do a lot of damage concerning compatibility.

Quote from PMD9409 :

Yes it is, but I thought it might help the "newer" people out. Can never have enough of a description IMO.

Well, I'm not sure. I feel we could attempt to create new "standard" tracks, and it seems logical to me they need to have codes/names compatible with LFS (4 chars). But of course the actual layout name can be anything.

Quote from PMD9409 :

Sure it would only update everytime you pass a split, but you don't need to know your position every millisecond and like I said it is better than nothing "last resort".

Hm, well, yes, I see. But there can be even better solutions, probably, using the "intermediate" InSim application idea I wrote about before plus the custom node map. Sure, it would require thinking and development, but generally it should be possible to feed to any existing InSim application slightly modified data about the layout race in progress and about the layout tract itself. That would be a highly transparent solution.

Quote from PMD9409 :

I realize TV Director will not work without nodes, unless someone can recreate it using XY coordinates. I still don't understand what you mean about the 4 chars max. Wouldn't it be reading "AS2X"?

Well, AS2X is no track, as I see it. It is an open site that may contain many custom tracks.

Quote from PMD9409 :

What we could do is just combine both of our ideas so AS13R can simply be changed to A13R. Since LFS tracks don't have overlapping first letters (B, S, F, K, W, A), we can simply just identify the enviroment with it, while identifying the configuration with a number (08 - 21 for Aston).

Hahaha, yes, sure, that's also an option. I could only suggest the custom layout track names to start at number 10, so that KY4, KY5, AS8, AS9 are open for developers in case they one day decide to make some of the custom tracks official.